From: Paolo Bonzini <pbonzini@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>, fred.konrad@greensocs.com
Cc: mttcg@greensocs.com, guillaume.delbergue@greensocs.com,
mark.burton@greensocs.com, qemu-devel@nongnu.org,
a.rigo@virtualopensystems.com
Subject: Re: [Qemu-devel] [RFC PATCH V2 3/3] cpus: introduce async_run_safe_work_on_cpu.
Date: Tue, 14 Jul 2015 00:56:20 +0200 [thread overview]
Message-ID: <55A44214.9040004@redhat.com> (raw)
In-Reply-To: <87r3ocjagd.fsf@linaro.org>
On 13/07/2015 18:20, Alex Bennée wrote:
>> +static void qemu_cpu_kick_thread(CPUState *cpu)
>> +{
>> +#ifndef _WIN32
>> + int err;
>> +
>> + err = pthread_kill(cpu->thread->thread, SIG_IPI);
>> + if (err) {
>> + fprintf(stderr, "qemu:%s: %s", __func__, strerror(err));
>> + exit(1);
>> + }
>> +#else /* _WIN32 */
>> + if (!qemu_cpu_is_self(cpu)) {
>> + CONTEXT tcgContext;
>> +
>> + if (SuspendThread(cpu->hThread) == (DWORD)-1) {
>> + fprintf(stderr, "qemu:%s: GetLastError:%lu\n", __func__,
>> + GetLastError());
>> + exit(1);
>> + }
>> +
>> + /* On multi-core systems, we are not sure that the thread is actually
>> + * suspended until we can get the context.
>> + */
>> + tcgContext.ContextFlags = CONTEXT_CONTROL;
>> + while (GetThreadContext(cpu->hThread, &tcgContext) != 0) {
>> + continue;
>> + }
>> +
>> + cpu_signal(0);
>> +
>> + if (ResumeThread(cpu->hThread) == (DWORD)-1) {
>> + fprintf(stderr, "qemu:%s: GetLastError:%lu\n", __func__,
>> + GetLastError());
>> + exit(1);
>> + }
>> + }
>> +#endif
>
> I'm going to go out on a limb and guess these sort of implementation
> specifics should be in the posix/win32 utility files, that is unless
> Glib abstracts enough of it for us.
As you found later, this part of the patch is just moving code around.
However, getting ultimately rid of this is basically the reason why I'm
interested in MTTCG. :)
>> +}
>> +
>> void run_on_cpu(CPUState *cpu, void (*func)(void *data), void *data)
>> {
>> struct qemu_work_item wi;
>> @@ -894,6 +933,76 @@ void async_run_on_cpu(CPUState *cpu, void (*func)(void *data), void *data)
>> qemu_cpu_kick(cpu);
>> }
>>
>> +void async_run_safe_work_on_cpu(CPUState *cpu, void (*func)(void *data),
>> + void *data)
>> +{
>> + struct qemu_work_item *wi;
>> +
>> + wi = g_malloc0(sizeof(struct qemu_work_item));
>> + wi->func = func;
>> + wi->data = data;
>
> Is there anything that prevents the user calling the function with the
> same payload for multiple CPUs?
Why? The data could be read only, or could be known to outlive the CPUs.
>> + wi->free = true;
>> +
>> + qemu_mutex_lock(&cpu->work_mutex);
>> + if (cpu->queued_safe_work_first == NULL) {
>> + cpu->queued_safe_work_first = wi;
>> + } else {
>> + cpu->queued_safe_work_last->next = wi;
>> + }
>> + cpu->queued_safe_work_last = wi;
>
> I'm surprised we haven't added some helpers to the qemu_work_queue API
> for all this identical boilerplate but whatever...
Yes, it should be using QSIMPLEQ. Can be done later.
It is indeed reasonable, but it should be used with great care.
Paolo
next prev parent reply other threads:[~2015-07-13 22:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 16:08 [Qemu-devel] [RFC PATCH V2 0/3] Multithread TCG async_safe_work part fred.konrad
2015-07-10 16:08 ` [Qemu-devel] [RFC PATCH V2 1/3] cpus: protect queued_work_* with work_mutex fred.konrad
2015-07-10 16:08 ` [Qemu-devel] [RFC PATCH V2 2/3] cpus: add a tcg_executing flag fred.konrad
2015-07-13 15:56 ` Alex Bennée
2015-07-13 16:10 ` Peter Maydell
2015-07-13 16:15 ` Paolo Bonzini
2015-07-13 16:36 ` Alex Bennée
2015-07-15 8:40 ` Frederic Konrad
2015-07-10 16:08 ` [Qemu-devel] [RFC PATCH V2 3/3] cpus: introduce async_run_safe_work_on_cpu fred.konrad
2015-07-13 16:20 ` Alex Bennée
2015-07-13 22:56 ` Paolo Bonzini [this message]
2015-07-13 11:53 ` [Qemu-devel] [RFC PATCH V2 0/3] Multithread TCG async_safe_work part Paolo Bonzini
2015-07-13 15:50 ` Alex Bennée
2015-07-15 7:44 ` Frederic Konrad
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=55A44214.9040004@redhat.com \
--to=pbonzini@redhat.com \
--cc=a.rigo@virtualopensystems.com \
--cc=alex.bennee@linaro.org \
--cc=fred.konrad@greensocs.com \
--cc=guillaume.delbergue@greensocs.com \
--cc=mark.burton@greensocs.com \
--cc=mttcg@greensocs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).