[Qemu-devel] [PATCH 0/3] Expose thread id through info cpus

[Qemu-devel] [PATCH 0/3] Expose thread id through info cpus

[Glauber Costa]

Hey,

This patch series expose the actual thread id of each cpu via the qemu
monitor. It is done through "info cpus", which I though would be the
most natural command to do it. (If you disagree, please voice it)

Goal is to allow tools like libvirt to easily grab it and feed taskset
for thinks like cpu pinning, etc

AFAIK, qemu runs all cpus in the same process, so for plain qemu, all cpus
will show the same id. But KVM can benefit from it, by overriding this data
in its ap initialization

Of the whole series, only the last patch is kvm-specific.

Many thanks to Anthony, who pointed me that this approach was possible.

[Qemu-devel] [PATCH] use a thread id variable

[Glauber Costa]

This patch introduces a "thread_id" variable to CPUState.
It's duty will be to hold the process, or more generally, thread
id of the current executing cpu

Signed-off-by: Glauber Costa <gcosta@redhat.com>
---
 qemu/cpu-defs.h |    1 +
 qemu/exec.c     |    5 +++++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/qemu/cpu-defs.h b/qemu/cpu-defs.h
index 6979c11..6387a2f 100644
--- a/qemu/cpu-defs.h
+++ b/qemu/cpu-defs.h
@@ -162,6 +162,7 @@ typedef struct CPUTLBEntry {
                                                                         \
     void *next_cpu; /* next CPU sharing TB cache */                     \
     int cpu_index; /* CPU index (informative) */                        \
+    int thread_id;							\
     /* user data */                                                     \
     void *opaque;                                                       \
                                                                         \
diff --git a/qemu/exec.c b/qemu/exec.c
index 960adcd..b82d26d 100644
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -340,6 +340,11 @@ void cpu_exec_init(CPUState *env)
     }
     env->cpu_index = cpu_index;
     env->nb_watchpoints = 0;
+#ifdef __WIN32
+    env->thread_id = GetCurrentProcessId();
+#else
+    env->thread_id = getpid();
+#endif
     *penv = env;
 }
 
-- 
1.5.0.6

[Qemu-devel] [PATCH] augment info cpus

[Glauber Costa]

This patch exposes the thread id associated with each
cpu through the already well known info cpus interface.

Signed-off-by: Glauber Costa <gcosta@redhat.com>
---
 qemu/monitor.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/qemu/monitor.c b/qemu/monitor.c
index 0874671..4ee0b19 100644
--- a/qemu/monitor.c
+++ b/qemu/monitor.c
@@ -335,6 +335,7 @@ static void do_info_cpus(void)
         if (env->halted)
             term_printf(" (halted)");
 #endif
+        term_printf(" thread_id=%d", env->thread_id);
         term_printf("\n");
     }
 }
-- 
1.5.0.6

[Qemu-devel] [PATCH] KVM: use actual thread id for vcpus

[Glauber Costa]

At kvm ap creation, update CPUState with the actual thread id.
For us, they are actually different

Signed-off-by: Glauber Costa <gcosta@redhat.com>
---
 qemu/qemu-kvm.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 051946e..45fddd3 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -19,6 +19,7 @@ int kvm_irqchip = 1;
 #include <libkvm.h>
 #include <pthread.h>
 #include <sys/utsname.h>
+#include <sys/syscall.h>
 
 extern void perror(const char *s);
 
@@ -49,6 +50,11 @@ struct vcpu_info {
     int stopped;
 } vcpu_info[256];
 
+static inline unsigned long kvm_get_thread_id(void)
+{
+    return syscall(SYS_gettid);
+}
+
 CPUState *qemu_kvm_cpu_env(int index)
 {
     return vcpu_info[index].env;
@@ -328,6 +334,7 @@ static void *ap_main_loop(void *_env)
 
     vcpu = &vcpu_info[env->cpu_index];
     vcpu->env = env;
+    vcpu->env->thread_id = kvm_get_thread_id();
     sigfillset(&signals);
     //sigdelset(&signals, SIG_IPI);
     sigprocmask(SIG_BLOCK, &signals, NULL);
@@ -374,6 +381,7 @@ int kvm_init_ap(void)
 
     vcpu = &vcpu_info[0];
     vcpu->env = first_cpu;
+    vcpu->env->thread_id = kvm_get_thread_id();
     signal(SIG_IPI, sig_ipi_handler);
     for (i = 1; i < smp_cpus; ++i) {
         kvm_init_new_ap(i, env);
-- 
1.5.0.6

[Qemu-devel] Re: [PATCH 0/3] Expose thread id through info cpus

[Glauber Costa]

Oops!

Forgot the -n option in git.

Anyway, the series is small and straightforward, so I'm not reposting
it. If there is any doubt about the ordering, please tell me.

On Wed, Mar 5, 2008 at 5:01 PM, Glauber Costa <gcosta@redhat.com> wrote:
> Hey,
>
>  This patch series expose the actual thread id of each cpu via the qemu
>  monitor. It is done through "info cpus", which I though would be the
>  most natural command to do it. (If you disagree, please voice it)
>
>  Goal is to allow tools like libvirt to easily grab it and feed taskset
>  for thinks like cpu pinning, etc
>
>  AFAIK, qemu runs all cpus in the same process, so for plain qemu, all cpus
>  will show the same id. But KVM can benefit from it, by overriding this data
>  in its ap initialization
>
>  Of the whole series, only the last patch is kvm-specific.
>
>  Many thanks to Anthony, who pointed me that this approach was possible.
>
>
>



-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

[Qemu-devel] Re: [PATCH 0/3] Expose thread id through info cpus

[Avi Kivity]

Glauber Costa wrote:
> Hey,
>
> This patch series expose the actual thread id of each cpu via the qemu
> monitor. It is done through "info cpus", which I though would be the
> most natural command to do it. (If you disagree, please voice it)
>
> Goal is to allow tools like libvirt to easily grab it and feed taskset
> for thinks like cpu pinning, etc
>
> AFAIK, qemu runs all cpus in the same process, so for plain qemu, all cpus
> will show the same id. But KVM can benefit from it, by overriding this data
> in its ap initialization
>
> Of the whole series, only the last patch is kvm-specific.
>
> Many thanks to Anthony, who pointed me that this approach was possible.
>
>
>   

Applied all, thanks.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] [PATCH] use a thread id variable

[Gilad Ben-Yossef]

Glauber Costa wrote:
> This patch introduces a "thread_id" variable to CPUState.
> It's duty will be to hold the process, or more generally, thread
> id of the current executing cpu
> 
>      env->nb_watchpoints = 0;
> +#ifdef __WIN32
> +    env->thread_id = GetCurrentProcessId();
> +#else
> +    env->thread_id = getpid();
> +#endif
>      *penv = env;


hmm... maybe I'm missing something, but in Linux at least I think you 
would prefer this to be gettid() rather then getpid as each CPU has it's 
own thread, not a different process.

No?

Gilad



-- 
Gilad Ben-Yossef <gilad@codefidence.com>
Chief Coffee Drinker

Codefidence Ltd. 		| Web: http://codefidence.com
Work: +972-3-7515563 ext. 201	| Mobile: +972-52-8260388

	"Your hovercraft is full of eels. For information on
	 emptying your hovercraft, turn to Section 2.6.a.17
	 of your hovercraft user manual".
		- The Monty Python technical writer

Re: [Qemu-devel] [PATCH] use a thread id variable

[Jamie Lokier]

Gilad Ben-Yossef wrote:
> Glauber Costa wrote:
> >This patch introduces a "thread_id" variable to CPUState.
> >It's duty will be to hold the process, or more generally, thread
> >id of the current executing cpu
> >
> >     env->nb_watchpoints = 0;
> >+#ifdef __WIN32
> >+    env->thread_id = GetCurrentProcessId();
> >+#else
> >+    env->thread_id = getpid();
> >+#endif
> >     *penv = env;
> 
> hmm... maybe I'm missing something, but in Linux at least I think you 
> would prefer this to be gettid() rather then getpid as each CPU has it's 
> own thread, not a different process.

On most platforms, getpid() returns the same value for all threads, so
it's not useful as a thread id.

On Linux, it depends which version of threads.  The old package,
LinuxThreads, has different getpid() for each thread.  The current one,
NPTL, has them all the same.

What you're supposed to do with pthreads in general is use pthread_self().

Btw, unfortunately pthread_self() is not safe to call from signal
handlers.

-- Jamie

Re: [Qemu-devel] [PATCH] use a thread id variable

[Gilad Ben-Yossef]

Jamie Lokier wrote:
> Gilad Ben-Yossef wrote:
>> Glauber Costa wrote:
>>> This patch introduces a "thread_id" variable to CPUState.
>>> It's duty will be to hold the process, or more generally, thread
>>> id of the current executing cpu
>>>
>>>     env->nb_watchpoints = 0;
>>> +#ifdef __WIN32
>>> +    env->thread_id = GetCurrentProcessId();
>>> +#else
>>> +    env->thread_id = getpid();
>>> +#endif
>>>     *penv = env;
>> hmm... maybe I'm missing something, but in Linux at least I think you 
>> would prefer this to be gettid() rather then getpid as each CPU has it's 
>> own thread, not a different process.
> 
> On most platforms, getpid() returns the same value for all threads, so
> it's not useful as a thread id.

Of course it does - this what POSIX says it should do (Linux 2.4 in 
compliance not withstanding). Which is why I suggested to use on Linux 
the non standard gettid() rather then getpid
> 
> On Linux, it depends which version of threads.  The old package,
> LinuxThreads, has different getpid() for each thread.  The current one,
> NPTL, has them all the same.


LinuxThreads behavior is wrong according to the POSIX standard. Of 
course, nothing else was possible with 2.4 kernels, so this is not an 
error on LinuxThreads coders part.


> What you're supposed to do with pthreads in general is use pthread_self().

Unfortunately, AFAIK the opaque handle that pthread_self() returns is 
not  quite meaningless outside of the process whereas what the non 
standard gettid() returns can actually be used to identify a thread from 
"outside" the process, like the shell.


Gilad

-- 
Gilad Ben-Yossef <gilad@codefidence.com>
Chief Coffee Drinker

Codefidence Ltd. 		| Web: http://codefidence.com
Work: +972-3-7515563 ext. 201	| Mobile: +972-52-8260388

	"Your hovercraft is full of eels. For information on
	 emptying your hovercraft, turn to Section 2.6.a.17
	 of your hovercraft user manual".
		- The Monty Python technical writer

Re: [Qemu-devel] [PATCH] use a thread id variable

[M. Warner Losh]

In message: <20080309115826.GA8077@shareable.org>
            Jamie Lokier <jamie@shareable.org> writes:
: Btw, unfortunately pthread_self() is not safe to call from signal
: handlers.

And also often times meaningless, as signal handlers can run in
arbitrary threads...

Warner

Re: [Qemu-devel] [PATCH] use a thread id variable

[M. Warner Losh]

In message: <47D3F9AF.2030408@codefidence.com>
            Gilad Ben-Yossef <gilad@codefidence.com> writes:
: > What you're supposed to do with pthreads in general is use pthread_self().
: 
: Unfortunately, AFAIK the opaque handle that pthread_self() returns is 
: not  quite meaningless outside of the process whereas what the non 
: standard gettid() returns can actually be used to identify a thread from 
: "outside" the process, like the shell.

gettid() is also non-standard.  If you want to interact with a thread,
you gotta use pthread_self() if you want your code to be portable.

Warner

Re: [kvm-devel] [Qemu-devel] [PATCH] use a thread id variable

[Daniel P. Berrange]

On Sun, Mar 09, 2008 at 11:26:43AM +0200, Gilad Ben-Yossef wrote:
> Glauber Costa wrote:
> > This patch introduces a "thread_id" variable to CPUState.
> > It's duty will be to hold the process, or more generally, thread
> > id of the current executing cpu
> > 
> >      env->nb_watchpoints = 0;
> > +#ifdef __WIN32
> > +    env->thread_id = GetCurrentProcessId();
> > +#else
> > +    env->thread_id = getpid();
> > +#endif
> >      *penv = env;
> 
> 
> hmm... maybe I'm missing something, but in Linux at least I think you 
> would prefer this to be gettid() rather then getpid as each CPU has it's 
> own thread, not a different process.

No, this patch is the generic QEMU code, which is single threaded, so
using getpid() is correct. Glauber  has a separate patch in this series
which implements the equivalent for KVM which does indeed use gettid()

Regards,
Dan.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] use a thread id variable

[Jamie Lokier]

M. Warner Losh wrote:
> In message: <20080309115826.GA8077@shareable.org>
>             Jamie Lokier <jamie@shareable.org> writes:
> : Btw, unfortunately pthread_self() is not safe to call from signal
> : handlers.
> 
> And also often times meaningless, as signal handlers can run in
> arbitrary threads...

That's usually the case, but sometimes it is useful.  Some causes of
signals are thread specific, or can be asked to be, and it's nice to
know which thread is receiving them (e.g. thread specific timers,
SIGIOs, write-protection SEGVs, and even sending messages with good
old pthread_kill (same reason as kernel uses IPIs)).

GCC's Boehm garbage collector uses pthread_self() from a signal
handler.  I've used gettid() in a signal handler on a few occasions.


-- Jamie

Re: [Qemu-devel] [PATCH] use a thread id variable

[Glauber Costa]

On Sun, Mar 9, 2008 at 11:52 AM, Gilad Ben-Yossef <gilad@codefidence.com> wrote:
> Jamie Lokier wrote:
>  > Gilad Ben-Yossef wrote:
>  >> Glauber Costa wrote:
>  >>> This patch introduces a "thread_id" variable to CPUState.
>  >>> It's duty will be to hold the process, or more generally, thread
>  >>> id of the current executing cpu
>  >>>
>  >>>     env->nb_watchpoints = 0;
>  >>> +#ifdef __WIN32
>  >>> +    env->thread_id = GetCurrentProcessId();
>  >>> +#else
>  >>> +    env->thread_id = getpid();
>  >>> +#endif
>  >>>     *penv = env;
>  >> hmm... maybe I'm missing something, but in Linux at least I think you
>  >> would prefer this to be gettid() rather then getpid as each CPU has it's
>  >> own thread, not a different process.
>  >
>  > On most platforms, getpid() returns the same value for all threads, so
>  > it's not useful as a thread id.
>
>  Of course it does - this what POSIX says it should do (Linux 2.4 in
>  compliance not withstanding). Which is why I suggested to use on Linux
>  the non standard gettid() rather then getpid
>
> >
>  > On Linux, it depends which version of threads.  The old package,
>  > LinuxThreads, has different getpid() for each thread.  The current one,
>  > NPTL, has them all the same.
>
>
>  LinuxThreads behavior is wrong according to the POSIX standard. Of
>  course, nothing else was possible with 2.4 kernels, so this is not an
>  error on LinuxThreads coders part.
>
>
>
>  > What you're supposed to do with pthreads in general is use pthread_self().
>
>  Unfortunately, AFAIK the opaque handle that pthread_self() returns is
>  not  quite meaningless outside of the process whereas what the non
>  standard gettid() returns can actually be used to identify a thread from
>  "outside" the process, like the shell.
>

Identifying a thread from the outside world is _exactly_ my intent
here, so pthread_self won't do.

I can easily write a wrapper to gettid() and use it. It would make the
kvm specific patch not-necessary, which is good.

The reason I used getpid in the first place, is that all raw qemu cpus
are in the same process anyway.

It's up to you, guys.

-- 
Glauber Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."