From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lytd1-0007FY-22 for qemu-devel@nongnu.org; Tue, 28 Apr 2009 16:10:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lytcw-0007BB-8L for qemu-devel@nongnu.org; Tue, 28 Apr 2009 16:10:06 -0400 Received: from [199.232.76.173] (port=35642 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lytcw-0007B8-69 for qemu-devel@nongnu.org; Tue, 28 Apr 2009 16:10:02 -0400 Received: from rv-out-0708.google.com ([209.85.198.243]:8568) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lytcv-0000VR-N4 for qemu-devel@nongnu.org; Tue, 28 Apr 2009 16:10:01 -0400 Received: by rv-out-0708.google.com with SMTP id c5so480431rvf.22 for ; Tue, 28 Apr 2009 13:10:00 -0700 (PDT) Message-ID: <49F76295.2010403@codemonkey.ws> Date: Tue, 28 Apr 2009 15:09:57 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] KVM brokenness due to IO thread changes References: <49F6B2D1.8070906@web.de> <20090428125146.GB19142@amt.cnet> <49F75F67.9040402@web.de> In-Reply-To: <49F75F67.9040402@web.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Marcelo Tosatti , qemu-devel Jan Kiszka wrote: > Marcelo Tosatti wrote: > >> Jan, >> >> On Tue, Apr 28, 2009 at 09:40:01AM +0200, Jan Kiszka wrote: >> >>> Hi, >>> >>> this is a heads-up, maybe someone has some time to look into this over >>> the day: I seems like the IO thread changes caused a few regressions to >>> the KVM mode. >>> >>> When I keep this feature disabled, I see strange hick-ups of the event >>> delivery mechanism, and the guest stops once in a while for a second or >>> so. Attaching strace makes the whole process terminate early (looks like >>> it triggers a race in the signal handling). And when I enable the IO >>> thread, I immediately get a deadlock on qemu_global_mutex. >>> >> Yes its borked. The iothread should signal the vcpu thread whenever it >> wants to grab the mutex lock, because unlike kvm-userspace it does not >> drop the global mutex when entering guest mode (VCPU_RUN ioctl). >> >> Anthony will commit patches to fix that soon. >> > > Looking forward. It's far more efficient to test my infrastructure > changes against the KVM mode. > N.B. he's seeing issues with the IO thread disabled. I've not seen this myself and my patch doesn't fix that problem. Regards, Anthony Liguori