All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Glauber Costa <glommer@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC v2] queue_work proposal
Date: Thu, 22 Oct 2009 15:37:05 -0200	[thread overview]
Message-ID: <20091022173705.GD4450@amt.cnet> (raw)
In-Reply-To: <1252000886-20611-1-git-send-email-glommer@redhat.com>

On Thu, Sep 03, 2009 at 02:01:26PM -0400, Glauber Costa wrote:
> Hi guys
> 
> In this patch, I am attaching an early version of a new "on_vcpu" mechanism (after
> making it generic, I saw no reason to keep its name). It allows us to guarantee
> that a piece of code will be executed in a certain vcpu, indicated by a CPUState.
> 
> I am sorry for the big patch, I just dumped what I had so we can have early directions.
> When it comes to submission state, I'll split it accordingly.
> 
> As we discussed these days at qemu-devel, I am using pthread_set/get_specific for
> dealing with thread-local variables. Note that they are not used from signal handlers.
> A first optimization would be to use TLS variables where available.
> 
> In vl.c, I am providing a version of queue_work for the IO-thread, and other for normal
> operation. The "normal" one should fix the problems Jan is having, since it does nothing
> more than just issuing the function we want to execute.
> 
> The io-thread version is tested with both tcg and kvm, and works (to the extent they were
> working before, which in kvm case, is not much)
> 
> Changes from v1:
>  * Don't open the possibility of asynchronous calling queue_work, suggested by
>    Avi "Peter Parker" Kivity
>  * Use a local mutex, suggested by Paolo Bonzini
> 
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> ---
>  cpu-all.h  |    3 ++
>  cpu-defs.h |   15 ++++++++++++
>  exec.c     |    1 +
>  kvm-all.c  |   58 +++++++++++++++++++---------------------------
>  kvm.h      |    7 +++++
>  vl.c       |   75 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  6 files changed, 125 insertions(+), 34 deletions(-)
> 
> diff --git a/cpu-all.h b/cpu-all.h
> index 1a6a812..529479e 100644
> --- a/cpu-all.h
> +++ b/cpu-all.h
> @@ -763,6 +763,9 @@ extern CPUState *cpu_single_env;
>  extern int64_t qemu_icount;
>  extern int use_icount;
>  
> +void qemu_queue_work(CPUState *env, void (*func)(void *data), void *data);
> +void qemu_flush_work(CPUState *env);
> +
>  #define CPU_INTERRUPT_HARD   0x02 /* hardware interrupt pending */
>  #define CPU_INTERRUPT_EXITTB 0x04 /* exit the current TB (use for x86 a20 case) */
>  #define CPU_INTERRUPT_TIMER  0x08 /* internal timer exception pending */

> @@ -3808,6 +3835,50 @@ void qemu_cpu_kick(void *_env)
>          qemu_thread_signal(env->thread, SIGUSR1);
>  }
>  
> +void qemu_queue_work(CPUState *env, void (*func)(void *data), void *data)
> +{
> +    QemuWorkItem wii;
> +
> +    env->queued_total++;
> +
> +    if (env == qemu_get_current_env()) {
> +        env->queued_local++;
> +        func(data);
> +        return;
> +    }
> +
> +    wii.func = func;
> +    wii.data = data;
> +    qemu_mutex_lock(&env->queue_lock);
> +    TAILQ_INSERT_TAIL(&env->queued_work, &wii, entry);
> +    qemu_mutex_unlock(&env->queue_lock);
> +
> +    qemu_thread_signal(env->thread, SIGUSR1);
> +
> +    qemu_mutex_lock(&env->queue_lock);
> +    while (!wii.done) {
> +        qemu_cond_wait(&env->work_cond, &qemu_global_mutex);
> +    }
> +    qemu_mutex_unlock(&env->queue_lock);

How's qemu_flush_work supposed to execute if env->queue_lock is held
here?

qemu_cond_wait() should work with env->queue_lock, and qemu_global_mutex
should be dropped before waiting and reacquired on return.

  parent reply	other threads:[~2009-10-22 17:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-03 18:01 [Qemu-devel] [RFC v2] queue_work proposal Glauber Costa
     [not found] ` <m3fxb350fe.fsf@neno.mitica>
2009-09-03 19:28   ` [Qemu-devel] " Glauber Costa
2009-10-22 17:37 ` Marcelo Tosatti [this message]
2009-10-22 18:57   ` [Qemu-devel] " Glauber Costa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091022173705.GD4450@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=glommer@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.