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 14:28:41 +0200 [thread overview]
Message-ID: <4AAA4279.3000004@siemens.com> (raw)
In-Reply-To: <20090911120641.GB4489@mothafucka.localdomain>
Glauber Costa wrote:
> On Fri, Sep 11, 2009 at 01:52:05PM +0200, Jan Kiszka wrote:
>> Glauber Costa wrote:
>>> 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.
>> As all this used to work fine in practice in upstream as well as in
>> qemu-kvm, I'm slightly unhappy about the current situation.
>>
>>> I already have something hacked up for this, will send as soon as I finish testing.
>> OK, looking forward.
>>
>> BTW, what's the state of the fix for the guest-debug regression under KVM?
> The last proposal I sent for queue_work would fix it, but it is a too big job, for just a fix.
> If you are not using the IO thread, I can do what I did in there: define on_vcpu to be
> conditional to the I/O thread, and in case it is not defined, just call the function
>
> What do you think?
IIUC, iothread and kvm is still broken in many ways here, so I'm fine
with a temporary workaround. Just make sure that it doesn't cause too
much merging pain downstream.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2009-09-11 12:28 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
2009-09-11 11:52 ` Jan Kiszka
2009-09-11 12:06 ` Glauber Costa
2009-09-11 12:28 ` Jan Kiszka [this message]
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=4AAA4279.3000004@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).