Expose thread id through info cpus

PATCH Applied Glauber Costa 7 participants 14 messages Mar 5, 2008 – Mar 17, 2008 KVM

lore

Share & tools

lore

Glauber Costa

author

2008-03-05 20:01 UTC #0 lore raw

cover Expose thread id through info cpus

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.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Glauber Costa

author

2008-03-05 20:01 UTC #1 lore raw

PATCH 1/1 use a thread id variable

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 <[email protected]>

---
 qemu/cpu-defs.h |    1 +
 qemu/exec.c     |    5 +++++
 2 files changed, 6 insertions(+), 0 deletions(-)

qemu/cpu-defs.h +1 -0

index 6979c11..6387a2f 100644
@@ -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;                                                       \
                                                                         \

qemu/exec.c +5 -0

index 960adcd..b82d26d 100644
@@ -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;
 }

Signature · 7 lines

1.5.0.6


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Glauber Costa

author

2008-03-05 20:01 UTC #2 lore raw

PATCH 1/1 augment info cpus

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

Signed-off-by Glauber Costa <[email protected]>

---
 qemu/monitor.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

qemu/monitor.c +1 -0

index 0874671..4ee0b19 100644
@@ -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");
     }
 }

Signature · 7 lines

1.5.0.6


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Glauber Costa

author

2008-03-05 20:01 UTC #3 lore raw

PATCH 1/1 KVM: use actual thread id for vcpus

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

Signed-off-by Glauber Costa <[email protected]>

---
 qemu/qemu-kvm.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

qemu/qemu-kvm.c +8 -0

index 051946e..45fddd3 100644
@@ -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);

Signature · 7 lines

1.5.0.6


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Gilad Ben-Yossef

2008-03-09 09:26 UTC #4 lore raw

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

In reply to Glauber Costa

qemu/exec.c void cpu_exec_init(CPUState *env) · line 348

Quoted 11 lines · 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
     env->nb_watchpoints = 0;
qemu/exec.c +5 -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

Signature · 16 lines

Gilad Ben-Yossef <[email protected]>
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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Jamie Lokier

2008-03-09 11:58 UTC #5 lore raw

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

Quoted 5 lines · Gilad Ben-Yossef

Quoted 4 lines · 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

Quoted 11 lines

qemu/exec.c void cpu_exec_init(CPUState *env) · line 348
Quoted 7 lines
    env->nb_watchpoints = 0;
qemu/exec.c +5 -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

Gilad Ben-Yossef

2008-03-09 14:52 UTC #6 lore raw

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

Quoted 17 lines · Jamie Lokier

Quoted 5 lines · Gilad Ben-Yossef
Quoted 4 lines · 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
Quoted 10 lines
qemu/exec.c void cpu_exec_init(CPUState *env) · line 348
Quoted 7 lines
    env->nb_watchpoints = 0;
qemu/exec.c +5 -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.

Quoted 2 lines

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

Quoted 4 lines

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.

Quoted 1 line

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

Signature · 16 lines

Gilad Ben-Yossef <[email protected]>
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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

M. Warner Losh

2008-03-09 16:12 UTC #7 lore raw

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

In message: <[email protected]>
Gilad Ben-Yossef <[email protected]> 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

Glauber Costa

2008-03-17 17:55 UTC #8 lore raw

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

In reply to Gilad Ben-Yossef

Quoted 37 lines · Gilad Ben-Yossef

Quoted 17 lines · Jamie Lokier
Quoted 5 lines · Gilad Ben-Yossef
Quoted 4 lines · 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
Quoted 10 lines
qemu/exec.c void cpu_exec_init(CPUState *env) · line 348
Quoted 7 lines
    env->nb_watchpoints = 0;
qemu/exec.c +5 -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.
Quoted 2 lines
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
Quoted 4 lines
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.

Quoted 7 lines

Quoted 1 line
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.

Signature · 10 lines

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

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

M. Warner Losh

2008-03-09 16:09 UTC #9 lore raw

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

In reply to Jamie Lokier

In message: <[email protected]>
Jamie Lokier <[email protected]> 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

Jamie Lokier

2008-03-09 20:01 UTC #10 lore raw

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

Quoted 7 lines · M. Warner Losh

In message: <[email protected]>
Jamie Lokier <[email protected]> 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

Daniel P. Berrange

2008-03-09 16:23 UTC #11 lore raw

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

In reply to Gilad Ben-Yossef

Quoted 5 lines · Gilad Ben-Yossef

Quoted 4 lines · 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

Quoted 12 lines

qemu/exec.c void cpu_exec_init(CPUState *env) · line 348
Quoted 7 lines
     env->nb_watchpoints = 0;
qemu/exec.c +5 -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.

Signature · 9 lines

|: 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 :|

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Glauber Costa

2008-03-05 20:07 UTC #12 lore raw

In reply to 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.

Quoted 19 lines · 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.

Signature · 10 lines

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

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Avi Kivity

Applied

2008-03-06 06:55 UTC #13 lore raw

In reply to Glauber Costa

Quoted 9 lines · 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

Quoted 10 lines

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.

Signature · 7 lines

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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/