From: Anthony Liguori <aliguori@us.ibm.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Avi Kivity <avi@redhat.com>,
Gleb Natapov <gleb@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v3] Replace qemu_system_cond with VCPU stop mechanism
Date: Mon, 22 Aug 2011 15:18:50 -0500 [thread overview]
Message-ID: <4E52B9AA.5010405@us.ibm.com> (raw)
In-Reply-To: <4E52854D.5040805@siemens.com>
On 08/22/2011 11:35 AM, Jan Kiszka wrote:
> On 2011-08-22 18:18, Avi Kivity wrote:
>> On 08/22/2011 06:46 PM, Jan Kiszka wrote:
>>> We can express the VCPU thread wakeup with the stop mechanism, saving
>>> both qemu_system_ready and the qemu_system_cond. For KVM threads, we can
>>> just enter the main loop as long as the thread is stopped. The central
>>> TCG thread is better held back before the loop as there can be side
>>> effects of the services called even when all CPUs are stopped.
>>>
>>> Creating VCPUs in stopped state will also be required for proper CPU
>>> hotplugging support.
>>>
>>>
>>> - /* and wait for machine initialization */
>>> - while (!qemu_system_ready) {
>>> - qemu_cond_wait(&qemu_system_cond,&qemu_global_mutex);
>>> + /* wait for initial kick-off after machine start */
>>> + while (!first_cpu->stopped) {
>>> + qemu_cond_wait(tcg_halt_cond,&qemu_global_mutex);
>>> }
>>
>> Seems inverted - do we want to wait until first_cpu is stopped, or while
>> first_cpu is stopped?
>
> Oops, fixed below.
>
>>
>> Do we want to process run_on_cpu() events after the machine is created
>> but before a cpu is started (if starting with -S)?
>
> -S affects vm_running, not stopped states of individual VCPUs. So they
> will get kicked off on main_loop entry, but then stop again due to
> vm_running == 0.
>
> Jan
>
> -------8<--------
>
> We can express the VCPU thread wakeup with the stop mechanism, saving
> both qemu_system_ready and the qemu_system_cond. For KVM threads, we can
> just enter the main loop as long as the thread is stopped. The central
> TCG thread is better held back before the loop as there can be side
> effects of the services called even when all CPUs are stopped.
>
> Creating VCPUs in stopped state will also be required for proper CPU
> hotplugging support.
>
> Signed-off-by: Jan Kiszka<jan.kiszka@siemens.com>
Applied. Thanks.
Regards,
Anthony Liguori
prev parent reply other threads:[~2011-08-22 20:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-22 15:46 [Qemu-devel] [RESEND][PATCH] Replace qemu_system_cond with VCPU stop mechanism Jan Kiszka
2011-08-22 16:18 ` Avi Kivity
2011-08-22 16:35 ` [Qemu-devel] [PATCH v3] " Jan Kiszka
2011-08-22 20:18 ` Anthony Liguori [this message]
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=4E52B9AA.5010405@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=pbonzini@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.