From: Jan Kiszka <jan.kiszka@siemens.com>
To: Glauber Costa <glommer@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
qemu-devel <qemu-devel@nongnu.org>, Avi Kivity <avi@redhat.com>
Subject: [Qemu-devel] Re: [COMMIT 733318e] don't call cpu_sychronize_state from reset handlers
Date: Fri, 11 Sep 2009 13:15:49 +0200 [thread overview]
Message-ID: <4AAA3165.4030009@siemens.com> (raw)
In-Reply-To: <200909092236.n89MaDVc020267@d01av01.pok.ibm.com>
Anthony Liguori wrote:
> From: Glauber Costa <glommer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> Doing this will make the vcpu ioctl be issued from the I/O thread, instead
> of cpu thread. The correct behaviour is to call it from within the cpu thread,
> as soon as we are ready to go.
Note that in the good old days, this used to work properly (in qemu-kvm)
as registers write-back was routed through on_vcpu.
>
> Signed-off-by: Glauber Costa <glommer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> diff --git a/hw/apic.c b/hw/apic.c
> index 2c414c1..9f1d25e 100644
> --- a/hw/apic.c
> +++ b/hw/apic.c
> @@ -938,8 +938,6 @@ static void apic_reset(void *opaque)
> APICState *s = opaque;
> int bsp;
>
> - cpu_synchronize_state(s->cpu_env);
> -
> bsp = cpu_is_bsp(s->cpu_env);
> s->apicbase = 0xfee00000 |
> (bsp ? MSR_IA32_APICBASE_BSP : 0) | MSR_IA32_APICBASE_ENABLE;
> diff --git a/vl.c b/vl.c
> index 8e5d9db..c6c6a6b 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3683,10 +3683,12 @@ static void *kvm_cpu_thread_fn(void *arg)
> while (!qemu_system_ready)
> qemu_cond_timedwait(&qemu_system_cond, &qemu_global_mutex, 100);
>
> + cpu_synchronize_state(env);
> +
> while (1) {
> + qemu_wait_io_event(env);
> if (cpu_can_run(env))
> qemu_cpu_exec(env);
> - qemu_wait_io_event(env);
> }
>
> return NULL;
> @@ -3711,6 +3713,9 @@ static void *tcg_cpu_thread_fn(void *arg)
> while (!qemu_system_ready)
> qemu_cond_timedwait(&qemu_system_cond, &qemu_global_mutex, 100);
>
> + for (env = first_cpu; env != NULL; env = env->next_cpu) {
> + cpu_synchronize_state(env);
> + }
> while (1) {
> tcg_cpu_exec();
> qemu_wait_io_event(cur_cpu);
>
This unfortunately breaks upstream KVM (Linux fails to detect the tiemr
IRQ properly). Is there a fix already in sight? I lost a bit overview of
all on_vcpu refactorings and kvm-register sync "simplifications".
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2009-09-11 11:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200909092236.n89MaDVc020267@d01av01.pok.ibm.com>
2009-09-10 10:16 ` [Qemu-devel] Re: [Qemu-commits] [COMMIT 733318e] don't call cpu_sychronize_state from reset handlers Gerd Hoffmann
2009-09-10 11:44 ` Avi Kivity
2009-09-10 12:29 ` Glauber Costa
2009-09-11 11:15 ` Jan Kiszka [this message]
2009-09-11 11:43 ` [Qemu-devel] " Glauber Costa
2009-09-11 11:52 ` Jan Kiszka
2009-09-11 12:06 ` Glauber Costa
2009-09-11 12:28 ` Jan Kiszka
2009-09-11 14:28 ` 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=4AAA3165.4030009@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.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 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).