From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mm5FB-00007E-LS for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:28:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mm5F6-0008WS-NH for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:28:48 -0400 Received: from [199.232.76.173] (port=36616 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mm5F6-0008WL-Gn for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:28:44 -0400 Received: from goliath.siemens.de ([192.35.17.28]:16803) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mm5F5-0003S0-Ti for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:28:44 -0400 Message-ID: <4AAA4279.3000004@siemens.com> Date: Fri, 11 Sep 2009 14:28:41 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <200909092236.n89MaDVc020267@d01av01.pok.ibm.com> <4AAA3165.4030009@siemens.com> <20090911114347.GA4489@mothafucka.localdomain> <4AAA39E5.5030107@siemens.com> <20090911120641.GB4489@mothafucka.localdomain> In-Reply-To: <20090911120641.GB4489@mothafucka.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [COMMIT 733318e] don't call cpu_sychronize_state from reset handlers List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: Anthony Liguori , qemu-devel , Avi Kivity 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 >>>>> >>>>> 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