From: Glauber Costa <glommer@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.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 08:43:47 -0300 [thread overview]
Message-ID: <20090911114347.GA4489@mothafucka.localdomain> (raw)
In-Reply-To: <4AAA3165.4030009@siemens.com>
On Fri, Sep 11, 2009 at 01:15:49PM +0200, Jan Kiszka wrote:
> 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.
I believe we should avoid the use of those things, specially at initialization. They are
totally racy and fragile. One way to do that, is to do all the reset functions inside the
cpu thread.
I already have something hacked up for this, will send as soon as I finish testing.
>
> >
> > 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:43 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 ` [Qemu-devel] " Jan Kiszka
2009-09-11 11:43 ` Glauber Costa [this message]
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=20090911114347.GA4489@mothafucka.localdomain \
--to=glommer@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=jan.kiszka@siemens.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).