On 13/08/2015 15:12, Paolo Bonzini wrote:

On 13/08/2015 14:17, Frederic Konrad wrote:
diff --git a/linux-user/main.c b/linux-user/main.c
index fdee981..fd06ce9 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -107,7 +107,7 @@ static int pending_cpus;
   /* Make sure everything is in a consistent state for calling
fork().  */
   void fork_start(void)
   {
-    pthread_mutex_lock(&tcg_ctx.tb_ctx.tb_lock);
+    qemu_mutex_lock(&tcg_ctx.tb_ctx.tb_lock);
       pthread_mutex_lock(&exclusive_lock);
       mmap_fork_start();
   }
@@ -129,11 +129,11 @@ void fork_end(int child)
           pthread_mutex_init(&cpu_list_mutex, NULL);
           pthread_cond_init(&exclusive_cond, NULL);
           pthread_cond_init(&exclusive_resume, NULL);
-        pthread_mutex_init(&tcg_ctx.tb_ctx.tb_lock, NULL);
+        qemu_mutex_init(&tcg_ctx.tb_ctx.tb_lock);
           gdbserver_fork(thread_cpu);
       } else {
           pthread_mutex_unlock(&exclusive_lock);
-        pthread_mutex_unlock(&tcg_ctx.tb_ctx.tb_lock);
+        qemu_mutex_unlock(&tcg_ctx.tb_ctx.tb_lock);
We might want to use tb_lock/unlock in user code as well instead of
calling directly qemu_mutex_* ?
You cannot do that because of the recursive locking assertions; the
child is not using qemu_mutex_unlock, it's using qemu_mutex_init.  So I
would have to add some kind of tb_lock_reset_after_fork() function which
is a bit ugly.

True.

Fred
@@ -676,6 +709,7 @@ static inline void code_gen_alloc(size_t tb_size)
               CODE_GEN_AVG_BLOCK_SIZE;
       tcg_ctx.tb_ctx.tbs =
               g_malloc(tcg_ctx.code_gen_max_blocks *
sizeof(TranslationBlock));
+    qemu_mutex_init(&tcg_ctx.tb_ctx.tb_lock);
Maybe we can initialize the mutex only for CONFIG_USER_ONLY?
It's okay, it doesn't consume system resources.

Paolo


Reply via email to