From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lyvgh-0000Ck-38 for qemu-devel@nongnu.org; Tue, 28 Apr 2009 18:22:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lyvgb-0000BE-Nf for qemu-devel@nongnu.org; Tue, 28 Apr 2009 18:22:02 -0400 Received: from [199.232.76.173] (port=44195 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lyvgb-0000BB-Kc for qemu-devel@nongnu.org; Tue, 28 Apr 2009 18:21:57 -0400 Received: from mx2.redhat.com ([66.187.237.31]:51156) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lyvgb-0003Pv-72 for qemu-devel@nongnu.org; Tue, 28 Apr 2009 18:21:57 -0400 Date: Tue, 28 Apr 2009 19:21:19 -0300 From: Marcelo Tosatti Subject: Re: [Qemu-devel] KVM brokenness due to IO thread changes Message-ID: <20090428222119.GA14775@amt.cnet> References: <49F6B2D1.8070906@web.de> <20090428125146.GB19142@amt.cnet> <49F75F67.9040402@web.de> <49F76295.2010403@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F76295.2010403@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jan Kiszka , qemu-devel On Tue, Apr 28, 2009 at 03:09:57PM -0500, Anthony Liguori wrote: >>>> 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. Jan, Can you please provide more details on how to reproduce it? You're using -nographic? All I see, with ping -c 0.1, is an eventual ~= 25ms in response time: 64 bytes from 192.168.122.140: icmp_seq=80 ttl=64 time=0.008 ms 64 bytes from 192.168.122.140: icmp_seq=81 ttl=64 time=0.008 ms 64 bytes from 192.168.122.140: icmp_seq=82 ttl=64 time=0.008 ms 64 bytes from 192.168.122.140: icmp_seq=83 ttl=64 time=0.023 ms 64 bytes from 192.168.122.140: icmp_seq=84 ttl=64 time=0.008 ms 64 bytes from 192.168.122.140: icmp_seq=85 ttl=64 time=0.008 ms 64 bytes from 192.168.122.140: icmp_seq=86 ttl=64 time=0.009 ms Which is also seen before the patches. Or even better, if you can bisect it... > I've not seen this myself and my patch doesn't fix that problem. > > Regards, > > Anthony Liguori